<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
	<META HTTP-EQUIV="CONTENT-TYPE" CONTENT="text/html; charset=utf-8">
    <TITLE>Why Is OWASP Changing ESAPI Encryption?</TITLE>
	<META NAME="GENERATOR" CONTENT="OpenOffice.org 3.0  (Linux)">
	<META NAME="CREATED" CONTENT="0;0">
	<META NAME="CHANGED" CONTENT="20100228;21125900">
	<META NAME="CHANGEDBY" CONTENT="Kevin W. Wall">
</HEAD>
<BODY LANG="en-US" DIR="LTR">
<H1 ALIGN=CENTER>Why Is OWASP Changing ESAPI Encryption?</H1>
<H2>Reasons for Change</H2>
<H3>Symmetric Encryption in ESAPI 1.4</H3>
<P STYLE="margin-bottom: 0in">The as-delivered, default ESAPI 1.4
encryption mechanism uses &quot;PBEWithMD5AndDES&quot;, a &quot;Password
Based Encryption&quot; algorithm. As implemented in ESAPI 1.4,
password (or pass phrase), taken from the property MasterPassword, is
concatenated with the salt as specified by the property MasterSalt,
and then repeated hashed 20 times using the MD5 message digest
algorithm. The intent of the salt and repetitive hashing is to slow
down dictionary attacks on the password. The result after the 20
iterations of hashing is used as the DES encryption key. The
encryption uses Cipher Block Chaining (CBC) cipher mode.</P>
<H3>Problems with Symmetric Encryption in ESAPI 1.4</H3>
<P>The problems with symmetric encryption in ESAPI 1.4 are many. Here
are some of the main issues:</P>
<OL>
	<LI><P>The implementation only supported a single encryption key.
	While this may be sufficient for some uses, clearly there are cases
	where multiple recipients are involved when you would like to use
	unique encryption keys for each recipient.</P>
	<LI><P>ESAPI 1.4 came with a default setting for MasterPassword and
	MasterSalt, thus not requiring that it be changed. How many of you
	forgot to change these?</P>
	<LI><P>Password based encryption is likely to be much weaker
	randomly choosing a secret key. For instance, if you restrict
	yourself to printable ASCII characters (which most people will), it
	would require a pass phrase of roughly 45 characters to be the
	equivalent of a randomly chosen 128-bit secret key.</P>
	<LI><P>The default algorithm, DES, only has an effective key length
	of 56-bits. This key size is too short and is in the realm of brute
	forcing within a short amount of time for most medium to large
	companies. (Fortunately, this could be addressed in part by changing
	the EncryptionAlgorithm property from &quot;PBEWithMD5AndDES&quot;
	to either &quot;PBEWithHmacSHA1AndDESede&quot; [if you are using JDK
	1.5 or later] or to &quot;PBEWithMD5AndTripleDES&quot; [if you are
	still using JDK 1.4]. Unfortunately, because of the implementation
	of <CODE>JavaEncryptor</CODE>, only &quot;password based encryption&quot;
	algorithms can be used in ESAPI 1.4.)</P>
	<LI><P>The symmetric encryption does not provide for any means of
	confirming message authenticity. Cryptographers consider ensuring
	message authenticity an important feature of modern cryptosystems.</P>
</OL>
<H3>Symmetric Encryption in ESAPI 2.0rc1 and 2.0rc2</H3>
<P STYLE="margin-bottom: 0in">By default, release candidates ESAPI
2.0-rc1 and 2.0-rc2 used the 256-bit AES cipher with the cipher mode
Electronic Code Book (ECB) for encryption with <CODE>Encryptor</CODE>
via the ESAPI reference implementation, <CODE>JavaEncryptor</CODE>.
ECB cipher mode is the simplest cipher mode to use, but it is also
cryptographically very weak. If more than one block of plaintext is
encrypted with the same key, those identical blocks of ciphertext
always encrypt to the same ciphertext block, thus revealing patterns
in the plaintext input. For example, these images from Wikipedia's
<A HREF="http://en.wikipedia.org/wiki/Block_cipher_modes_of_operation">Block
cipher modes of operation</A> illustrate this point well: 
</P>
<TABLE BORDER=0 CELLPADDING=4 CELLSPACING=0>
	<TR>
		<TD>
			<P ALIGN=CENTER><FONT COLOR="#000080"><A HREF="http://en.wikipedia.org/wiki/File:Tux.jpg"><FONT COLOR="#000080"><IMG SRC="http://upload.wikimedia.org/wikipedia/commons/5/56/Tux.jpg" NAME="graphics1" ALT="Original Tux image" ALIGN=BOTTOM WIDTH=196 HEIGHT=216 BORDER=1></FONT></A></FONT></P>
		</TD>
		<TD>
			<P ALIGN=CENTER><FONT COLOR="#000080"><A HREF="http://en.wikipedia.org/wiki/File:Tux_ecb.jpg"><FONT COLOR="#000080"><IMG SRC="http://upload.wikimedia.org/wikipedia/commons/f/f0/Tux_ecb.jpg" NAME="graphics2" ALT="Tux image encrypted using ECB mode" ALIGN=BOTTOM WIDTH=196 HEIGHT=216 BORDER=1></FONT></A></FONT></P>
		</TD>
		<TD>
			<P ALIGN=CENTER><FONT COLOR="#000080"><A HREF="http://en.wikipedia.org/wiki/File:Tux_secure.jpg"><FONT COLOR="#000080"><IMG SRC="http://upload.wikimedia.org/wikipedia/commons/a/a0/Tux_secure.jpg" NAME="graphics3" ALT="Tux image encrypted with other modessuch as CBC" ALIGN=BOTTOM WIDTH=196 HEIGHT=216 BORDER=1></FONT></A></FONT></P>
		</TD>
	</TR>
	<TR>
		<TD>
			<P ALIGN=CENTER><I>Original Tux image</I></P>
		</TD>
		<TD>
			<P ALIGN=CENTER><I>Image encrypted using ECB mode</I></P>
		</TD>
		<TD>
			<P ALIGN=CENTER><I>Image encrypted using modes other than ECB</I></P>
		</TD>
	</TR>
</TABLE>
<P>Ciphertext encrypted with ECB cipher mode are also subject to
&quot;block replay attacks&quot;. See Bruce Schneier's <A HREF="http://www.google.com/url?sa=t&amp;source=web&amp;ct=res&amp;cd=2&amp;url=http%3A%2F%2Fbooks.google.com%2Fbooks%3Fid%3DA6ZO2D6ayNwC%26pg%3DPT216%26lpg%3DPT216%26dq%3Decb%2B%2522block%2Breplay%2522%26source%3Dbl%26ots%3DiEbAWQpu0e%26sig%3D8xiUva4XKaAOfPJEPsULPAJPk88%26hl%3Den%26ei%3Da6yISoLQPJOuMI-Z_OkE%26sa%3DX%26oi%3Dbook_result%26ct%3Dresult%26resnum%3D2&amp;ei=a6yISoLQPJOuMI-Z_OkE&amp;rct=j&amp;q=ecb+%22block+replay%22&amp;usg=AFQjCNF-IjrE4dL7M2LELh48hYPP6A_bpQ"><I>Applied
Cryptography: protocols, algorithms, and source code</I> </A>for
details. 
</P>
<P>In both ESAPI 2.0-rc1 and 2.0-rc2, one can choose other block
ciphers (e.g. Blowfish) or other key sizes (e.g., 512-bit AES), but
encryption in ESAPI 2.0-rc1 and 2.0-rc2 <I>only</I> support ECB
cipher mode with no padding; it cannot be used to decrypt data
encrypted with anything other than an algorithm using ECB cipher mode
and no padding. Most encryption (outside of ESAPI) uses some other
cipher mode (e.g., Cipher Block Chaining (CBC) mode) and some sort of
padding scheme, such as PKCS#5 padding, meaning that they are many
situations where ESAPI encryption would not be suitable.</P>
<H3>Problems with Symmetric Encryption in ESAPI 2.0-rc1 and 2.0-rc2</H3>
<P>The problems with symmetric encryption in ESAPI 2.0-rc1 and 2.0rc2
are many. Here are some of the main issues:</P>
<OL>
	<LI VALUE=1><P>The implementation only supported a single encryption
	key. While this may be sufficient for some uses, clearly there are
	cases where multiple recipients are involved when you would like to
	use unique encryption keys for each recipient.</P>
	<LI><P>ESAPI 2.0-rc1 and 2.0-rc2 came with a default settings for
	Encryptor.MasterKey and Encryptor.MasterSalt, thus not requiring
	that these be changed. How many of you forgot to change these?</P>
	<LI><P>Because the reference implementation in <CODE>JavaEncryptor</CODE>
	allows no means to specify an Initialization Vector (IV), only the
	weak ECB cipher mode can be used.</P>
	<LI><P>The symmetric encryption does not provide for any means of
	confirming message authenticity. Cryptographers consider ensuring
	message authenticity an important feature of modern cryptosystems.</P>
</OL>
<H2>The Encryption Changes in ESAPI 2.0-rc3 and Later</H2>
<P>Briefly speaking, the changes being implemented for ESAPI Java 2.0
are: 
</P>
<OL>
	<LI><P STYLE="margin-bottom: 0in">Starting in ESAPI Java 2.0-rc3,
	the <I>default</I> cipher transformation is changing to
	&quot;AES-128/CBC/PKCS5Padding&quot; (i.e., 128-bit AES in CBC
	cipher mode and PKCS#5 padding) with a random IV. The main reason
	that 128-bit AES was chosen over 256-bit AES for the default is that
	128-bit AES is slightly faster than 256-bit AES, and it does not
	require you downloading the Unlimited Strength Jurisdiction Policy
	files from Sun Microsystems. For those believing that 128-bit AES is
	not sufficiently strong--bruting forcing it (except perhaps with a
	reasonable quantum computer) is still not feasible--and certain key
	related attacks (see Biryukov, Dunkelman, Keller, Khovratovich, and
	Shamir's <A HREF="http://eprint.iacr.org/2009/374">Cryptology ePrint
	Archive: Report 2009/374 -- Key Recovery Attacks of Practical
	Complexity on AES Variants With Up To 10 Rounds </A>for further
	details) show that longer key sizes in AES may not always be the
	best.</P>
	<LI><P STYLE="margin-bottom: 0in">Because cipher modes other than
	ECB require an Initialization Vector (IV), a mechanism to handle
	both fixed and random IVs has been added. The use of the “fixed”
	IV should only be considered if there is a need to be compatible
	with some legacy software or third party software package. Those
	cases should be rare.</P>
	<LI><P STYLE="margin-bottom: 0in">The original attempt to preserve
	backward compatibility with ESAPI Java 1.4 (via
	<CODE>org.owasp.esapi.reference.crypto.LegacyJavaEncryptor</CODE>)
	has been removed. This was put to a vote on Jan 31, 2010 before both
	the ESAPI Users and ESAPI Developers mailing lists and the lack of
	response was deafening. There literally was but a single response
	and that was to kill off <CODE>LegacyJavaEncryptor</CODE><CODE><FONT FACE="Thorndale AMT, serif">.</FONT></CODE>
	(By this time, the two symmetric encryption interfaces in <CODE>Encryptor</CODE>
	had already been deprecated.) 
	</P>
	<LI><P>The byte-encoding has been changed from native byte encoding
	to UTF-8 byte-encoding throughout ESAPI 2.0 and not just for
	encryption. This was needed so that one could (say) encrypt on a
	Sparc running Solaris and then move the encrypted data to an Intel
	host running Windows and still be able to decrypt the data. Without
	this change to use uniform encoding throughout, this could not be
	guaranteed.</P>
</OL>
<H2>The Good, the Bad, and the Ugly</H2>
<P>Or put another way, there are always trade-offs to be made... 
</P>
<H3>The Good</H3>
<P>We get improved security by encouraging the use of stronger cipher
modes (and ESAPI is all about &quot;enterprise security&quot;,
right?). Furthermore, it is possible to choose a preferred JCE
provider for ESAPI and ESAPI will attempt to use that provider. For
example, if you wish to use Bouncy Castle rather than the SunJCE, you
can do so. One place where this might be a significant advantage is
if you need to use a FIPS 140-2 compliant JCE implementation. Whereas
in production environments, you ultimately will want to ensure this
by editing your <FONT FACE="DejaVu Sans Mono, sans-serif">$JAVA_HOME/jre/lib/security/java.security</FONT>
file, this is often inconvenient for developers who simply wish to
test because this file often requires super-user access to alter. In
such cases, setting the new ESAPI property
<FONT FACE="DejaVu Sans Mono, sans-serif">Encryptor.PreferredJCEProvider</FONT>
to the fully qualified class name of your FIPS 140-2 JCE provider in
your <FONT FACE="Thorndale AMT, serif"><B>ESAPI.properties</B></FONT>
file and you can test without any other changes to your code or you
environment.</P>
<P>We also get message authenticity as long as we don't use any of
the deprecated encryption methods or intentionally disable it. (The
only <I>sane</I> reason for intentionally disabling the MAC
calculation is for FIPS 140-2 compliance. This MAC calculation
requires deriving two new <FONT FACE="DejaVu Sans Mono, sans-serif">SecretKey</FONT>s
from the original key—one to use for message authenticity and a
second one to use for message confidentiality. While we believe that
this mechanism is secure [it was originally suggested by professional
cryptographers], this key derivation would not be using FIPS 140-2
approved code. Therefore if you require FIPS 140-2 compliance, you
should set “<FONT FACE="DejaVu Sans Mono, sans-serif">Encryptor.CipherText.useMAC=false</FONT>”
in your <FONT FACE="Thorndale AMT, serif"><B>ESAPI.properties</B></FONT>
file.)</P>
<H3>The Bad</H3>
<P>With cipher modes that require an IV, the same IV must be used
both to encrypt and decrypt. While it is not required that the IV be
kept secret from adversaries, there are some attacks that are
possible if the adversary is permitted to alter the IV at will and
observe the results of the ensuing decryption attempt. 
</P>
<P>So that leaves two choices for the IV: 
</P>
<UL>
	<LI><P STYLE="margin-bottom: 0in">Using a <I><B>fixed IV</B></I>:
	The IV can be agreed upon out-of-band by the parties exchanging
	encrypted messages. In this way, the encrypted data that is stored
	and/or transmitted can be limited to only the <I>raw</I> ciphertext.
	(<U><B>WARNING</B></U><SPAN STYLE="text-decoration: none"><SPAN STYLE="font-weight: normal">:
	This case should be reserved for situations requiring compatibility
	with legacy or third party software packages.)</SPAN></SPAN></P>
	<LI><P>Using a <I><B>random IV</B></I>: Most cryptographers prefer
	to use a random IV, typically a different one with each message to
	be encrypted. However, doing so on encrypted data that will be
	persisted (e.g., to a database) or transmitted to the recipient this
	random IV must be stored / made known. Therefore, the raw ciphertext
	can no longer suffice; whatever random IV that was chosen must be
	communicated. 
	</P>
</UL>
<P>Likewise, the use of padding is going to add some overhead to the
length of the ciphertext.</P>
<P STYLE="margin-bottom: 0in">For example, a short plaintext of 0-15
bytes, this overhead can be around 200% of the total plaintext size.
This overhead diminishes (as a percent of the total plaintext size)
as the plaintext size increases. Here is a table that illustrates
this:</P>
<A NAME="encryption-overhead">
<P STYLE="margin-bottom: 0in"><BR>
</P>
</A>
<TABLE WIDTH=100% BORDER=1 BORDERCOLOR="#000000" CELLPADDING=4 CELLSPACING=0>
	<COL WIDTH=64*>
	<COL WIDTH=64*>
	<COL WIDTH=64*>
	<COL WIDTH=64*>
	<TR VALIGN=TOP>
		<TD WIDTH=25%>
			<P ALIGN=CENTER><B>Original input length of plaintext <BR>(#
			bytes)</B></P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=CENTER><B>Base64-encoded length of ciphertext (with IV
			and padding) encrypted with 128-bit AES in CBC mode, but no MAC<SUP>1</SUP></B></P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=CENTER><B>Length of raw portable serialized CipherText
			byte array, containing IV, padding, and MAC, and encrypted with
			128-bit AES in CBC mode</B></P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=CENTER><B>Length of raw portable serialized CipherText,
			containing IV, padding, and MAC, and encrypted with 128-bit AES in
			CBC mode as a Base64-encoded string</B></P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>0-15</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>44</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>102</P>
		</TD>
		<TD WIDTH=25% SDVAL="137" SDNUM="1033;">
			<P>137</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>16-31</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>64</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>118</P>
		</TD>
		<TD WIDTH=25% SDVAL="162" SDNUM="1033;">
			<P>162</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>32-47</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>88</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>134</P>
		</TD>
		<TD WIDTH=25% SDVAL="182" SDNUM="1033;">
			<P>182</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>48-63</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>108</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>150</P>
		</TD>
		<TD WIDTH=25% SDVAL="202" SDNUM="1033;">
			<P>202</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>64-79</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>128</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>166</P>
		</TD>
		<TD WIDTH=25% SDVAL="222" SDNUM="1033;">
			<P>222</P>
		</TD>
	</TR>
	<TR VALIGN=TOP>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>… etc.  Each additional 16 bytes of plaintext...</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>...adds ~20 additional bytes</P>
		</TD>
		<TD WIDTH=25%>
			<P ALIGN=LEFT>...adds 16 additional bytes</P>
		</TD>
		<TD WIDTH=25%>
			<P>...adds 20 additional bytes</P>
		</TD>
	</TR>
</TABLE>
<P>__________________________________</P>
<P>1. That is, the <FONT FACE="DejaVu Sans Mono, sans-serif">String</FONT>
that is returned by the deprecated <FONT FACE="DejaVu Sans Mono, sans-serif">Encryptor.decrypt(String)</FONT>
method.</P>
<P>As you can see, since the size of the IV and the amount of padding
bytes are fixed at a maximum, this overhead goes down as the length
of the plaintext message increases. The IV is always a fixed length
for a given cipher; it is always the same as the cipher block size.
The padding can vary, but for PKCS5 padding, the padding will be
between 1 to the cipher block size (in bits) / 8 bytes. For AES, the
cipher block size is 128-bits, but more typically, a cipher's block
size is 64-bits so the padding would be between 1 to 16 bytes for AES
and 1 to 8 bytes for a 64-bit block size cipher and the IV would be
IV would be 16 bytes for AES and 8 bytes for most other ciphers. 
</P>
<H3>The Ugly</H3>
<P>Well, so far, this &quot;bad&quot; news may be bad for you but
good for your database and/or storage vendor, but you probably can
live with it, especially if you are willing to do a little bit of
recoding of your database table sizes.</P>
<P>But wait Skippy, don't go running off just quite yet. As Robert
Heinlein wrote in his 1966 novel <I>The Moon is a Harsh Mistress</I>
&quot;There ain't no such thing as a free lunch&quot;. (Some of us
more hardened cynics know it more commonly as <I>TANSTAAFL</I>.) 
</P>
<P>As mentioned earlier, backward compatibility with ESAPI 1.4
(originally planned via <CODE>LegacyJavaEncryptor</CODE>) has been
removed because of apparent lack of interest. What this means is if
you are one of the unlucky stuckeys who are using ESAPI 1.4 symmetric
encryption to encrypt data and you have persisted this data (and this
would <I>include </I><SPAN STYLE="font-style: normal">the use of the
</SPAN><FONT FACE="DejaVu Sans Mono, sans-serif"><SPAN STYLE="font-style: normal">org.owasp.esapi.EncryptedProperties</SPAN></FONT>
<SPAN STYLE="font-style: normal">class in ESAPI 1.4)</SPAN>, you will
first have to <I>decrypt </I><SPAN STYLE="font-style: normal">this
encrypted data using ESAPI 1.4 before using encryption with ESAPI
2.0. As they say, “we are sorry for the inconvenience”, but there
was an opportunity to make your voice heard so we refuse to take </SPAN><I>all
</I><SPAN STYLE="font-style: normal">the blame.</SPAN></P>
<P>In addition, all this backward compatibility and flexibility comes
at the extra cost of complexity, and not <I>merely</I> additional
complexity in the reference implementation. There is also some
additional complexity in the ESAPI <CODE>Encryptor</CODE> interfaces
as well.</P>
<P>In particular, there new classes for plaintext (<FONT FACE="DejaVu Sans Mono, sans-serif">PlainText</FONT>)
and ciphertext (<CODE>CipherText)</CODE> class to coalesce all this
complexity of handling the ciphertext result from encryption
operations. And then there are new encryption and decryption methods
for the <CODE>Encryptor</CODE> interface. Specifically, the encrypt
and decrypt methods have been generalized as: 
</P>
<PRE STYLE="margin-left: 0.49in"><FONT COLOR="#000000"><FONT FACE="Monospace">CipherText encrypt(SecretKey key, PlainText plaintext)</FONT></FONT>
<FONT COLOR="#000000">        <FONT FACE="Monospace">throws EncryptionException;</FONT></FONT></PRE><P STYLE="margin-bottom: 0in">
and 
</P>
<PRE STYLE="margin-left: 0.49in"><FONT COLOR="#000000"><FONT FACE="Monospace">PlainText decrypt(SecretKey key, CipherText ciphertext)</FONT></FONT>
<FONT COLOR="#000000">        <FONT FACE="Monospace">throws EncryptionException</FONT></FONT></PRE><P>
(There are also two corresponding encrypt / decrypt methods that omit
the initial <FONT FACE="DejaVu Sans Mono, sans-serif">SecretKey</FONT>
argument and instead use the <FONT FACE="DejaVu Sans Mono, sans-serif">SecretKey</FONT>
based on <FONT FACE="DejaVu Sans Mono, sans-serif">Encryptor.MasterKey</FONT>.)</P>
<P>The two existing interfaces from ESAPI 1.4 and earlier:</P>
<PRE STYLE="margin-left: 0.49in; margin-bottom: 0.2in">String encrypt(String plaintext) throws EncryptionException</PRE><P STYLE="margin-bottom: 0in">
and 
</P>
<PRE STYLE="margin-left: 0.49in; margin-bottom: 0.2in">String decrypt(String ciphertext) throws EncryptionException</PRE><P>
are still supported but have been <I>deprecated</I>, mainly because
they do not support integrity / authenticity checks which most
cryptographers consider essential. Also these older String-based
encrypt() / decrypt() interfaces have slightly different semantics
than do their ESAPI 1.4 counterparts in that these methods default to
CBC cipher mode, PKCS5Padding, and a random IV. This means that at a
minimum, the IV must be included as the resulting base64-encoded
“ciphertext”.</P>
<P>However, this difference in cipher mode means that if you have
data that was previously encrypted using ESAPI 1.4 or earlier, you
will not be able to decrypt it using the ESAPI 2.0</P>
<PRE STYLE="margin-left: 0.49in; margin-bottom: 0.2in">String decrypt(String ciphertext) throws EncryptionException</PRE><P>
method. If you require such compatibility, you may contact the
author, <a href="mailto:kevin.w.wall@gmail.com">Kevin W. Wall</a>,
for assistance.
</P>
<P>Note that while the new String-based encrypt() / decrypt() methods
use the stronger CBC cipher mode with a random IV, they still do not
ensure authenticity and integrity so the more general encrypt() /
decrypt() methods should be preferred over the String-based ones.
(See below for examples of how to use these new methods.)</P>
<H2>Further Details</H2>
<P>Further details are provided in the <CODE>Encryptor</CODE> Javadoc
and the “Symmetric Encryption” section of the ESAPI User Guide.</P>
</BODY>
</HTML>
